\documentclass[a4paper,12pt]{article}

\usepackage{fancyhdr}
% \usepackage{ulem}     % do podkreśleń, skreśleń (psuł wygląd tagu \emph)
\usepackage[utf8]{inputenc}
\usepackage{polski}
\usepackage[polish]{babel}
\usepackage{a4wide}

\pagestyle{fancy}

\renewcommand{\headheight}{16pt}

\newcommand{\HRule}{\rule{\linewidth}{0.1mm}}

\begin{document}

\begin{titlepage}
\begin{center}
	\textsc{Inżynieria oprogramowania - Grupa dra inż. Leszka Grocholskiego}\\
	\textsc{II UWr 2009/2010}\\[4cm]

	\HRule \\[2cm]

	Aleksandra Kloc, Adam Grycner, Mateusz Łyczek\\[1cm]

	\textsc{\Large Wasza-fota.pl}\\[0.3cm]
	\textsc{\large Koncepcja zarządzania przedsięwzięciem}\\[2cm]

	\HRule\\[2.5cm]
	
\begin{center}
\textbf{Historia zmian tego dokumentu}
\end{center}
\begin{table}[h]
	\begin{center}
	{\footnotesize
	\begin{tabular}{|l|c|p{2.8cm}|l|}
		\hline
		\textbf{Data} & \textbf{Wersja} & \textbf{Autor} & \textbf{Opis zmian}\\
		\hline
		2009/11/18 & 1.0 & Zespół & Utworzenie dokumentu\\
		2009/12/7 & 1.1 & Aleksandra Kloc & Koncepcja zarządzania jakością\\
                2009/12/8 & 1.3 & Adam Grycner & Ocena pracochłonności, Narzędzia wspomagające\\
                2009/12/14 & 1.4 & Aleksandra Kloc & Koncepcja zarządzania ryzykiem, Koncepcja\\
                & & & zarządzania jakością, Koncepcja zarządzania zmianami\\
                & & & wymagań i kodu\\
                2009/12/14 & 1.5 & Mateusz Łyczek & Testowanie, Kosmetyczne zmiany i skład dokumentu\\
		\hline
	\end{tabular}
	}
	\end{center}
	\caption{Historia zmian}
\end{table}
	
	
\end{center}
\end{titlepage}

\tableofcontents
\newpage

\section{Model zarządzania przedsięwzięciem}
Projekt \emph{wasza-fota.pl} będzie zarządzany zgodnie z zasadami \emph{RUP - Rational Unified Process}.
\section{Narzędzia wspomagające zarządzanie przedsięwzięciem}
Przy tworzeniu naszego projektu wykorzystamy następujące narzędzia wspomagające rozwój projektu m.in.:
\begin{itemize}
 \item Google code - system kontroli wersji, który ułatwia komunikację zespołu. Dzięki temu narzędziu mamy pewność, że programiści będą pracowali zawsze nad najnowszą wersją projektu.
 \item Microsoft project - program do zarządzania projektami
 \item Netbeans - zintegrowane środowisko programistyczne
 \item phpMyAdmin - narzędzie służące do łatwego zarządzania bazami danych
 \item DIA - oprogramowanie do tworzenia diagramów ER
 \item Umbrello - narzędzie do tworzenia diagramów UML
 \item Bugzilla - system kontroli błędów
 \item Glade - narzędzie do tworzenia interfejsów
 \item QtDesigner - oprogramowanie wspomagające tworzenie interfejsów
 \item Firefox - przeglądarka internetowa potrzebna do wykonania testów poprawności portalu
 \item \LaTeX - system składu drukarskiego
 \item Kile - edytor do \LaTeX
 \item Acrobat Reader - przeglądarka dokumentów pdf
 \item dvipdf - narzędzie do zamiany plików w formacie dvi na format pdf
\end{itemize}

\section[Metody szacowania pracochłonności]{Opis metody szacowania pracochłonności przedsięwzięcia}
\subsection{Oszacowanie pracochłonności}
\subsubsection{Szacowanie rozmiaru oprogramowania}
W celu oszacowania rozmiaru oprogramowania posłużymy się metodą punktów funkcyjnych. Wstępne oszacowanie (UT) przedstawia poniższa tabela:
\begin{center}
\begin{tabular}{|l|l|l|l|l|}
\hline
\textbf{Typ funkcji} & \textbf{Proste} & \textbf{Średnie} & \textbf{Złożone} & \textbf{Razem} \\ \hline
Wejście & 10 X 3 & 5 X 4 & 3 X 6 & 68 \\
Wyjście & 6 X 4 & 4 X 5 & 1 X 7 & 44 \\
Zapytania & 2 X 3 & 20 X 5 & 10 X 6 & 166 \\
Wew. pliki danych & 5 X 7 & 2 X 10 & 5 X 15 & 130 \\
Zew. interfejs & 0 X 5 & 2 X 7 & 4 X 10 & 54 \\ \hline
\multicolumn{4}{|l|}{Wstępne oszacowanie} & 462 \\ \hline
\end{tabular}
\end{center}
Współczynniki wpływu są następujące (każdy z nich jest wartością całkowitą z zakresu $0..5$, gdzie $0$ -- nie dotyczy; $5$ -- zasadnicze znaczenie):

\begin{enumerate}
\item Czy jest wymagane przesyłanie danych? 5
\item Czy są funkcje przetwarzania rozproszonego? 5
\item Czy wydajność ma kluczowe znaczenie? 5
\item Czy system ma działać w mocno obciążonym środowisku operacyjnym? 3
\item Czy system wymaga wprowadzenia danych on-line? 5
\item Czy wewnętrzne przetwarzanie jest złożone? 5
\item Czy kod ma być re-używalny? 4
\item Czy wejścia, wyjścia, pliki i zapytania są złożone? 5
\item Czy wprowadzanie danych on-line wymaga transakcji obejmujących wiele ekranów lub operacji? 4
\item Czy pliki główne są aktualizowane on-line? 5
\item Czy system ma mieć automatyczne konwersje i instalacje? 3
\item Czy system wymaga mechanizmu kopii zapasowych i odtwarzania? 5
\item Czy system jest projektowany dla wielu instalacji w różnych organizacjach? 5
\item Czy aplikacja jest projektowana aby wspomagać zmiany i być łatwą w użyciu przez użytkownika? 5
\end{enumerate}   

Suma współczynników wpływu wynosi więc 73. Mnożnik współczynników wpływu liczymy z wzoru:

\[ CM = 0.65 + 0.01 \cdot \textrm{suma współczynników wpływu} \]

a więc w naszym przypadku CM = 1.36. Aby obliczyć punkty funkcyjne korzystamy z wzoru:

\[ FP = UT \cdot CM \]

W naszym przypadku:

\[ FP = 462\cdot 1.37 = 632\]

Żeby uzyskać szacowaną ilość wierszy kodu (LOC, ang. Lines of code) należy pomnożyć FP razy współczynnik ,,zwięzłości języka'', który szacujemy na 21 (Python) oraz 20 (PHP). Około 2/5 kodu będzie napisana w pythonie, a 3/5 napisana w PHP. Wobec powyższych obliczeń, szacowana ilość linii kodu wynosi 13 911 linii, w zaokrągleniu 14 000.
\subsubsection{Szacowanie pracochłonności}
Do oszacowania pracochłonności projektu wykorzystamy metodę COCOMO II (model post-architektoniczny). Jednostką używaną w tej metodzie jest PM (osobomiesiąc). Podstawowy wzór określający pracochłonność ($PM_\textrm{nominal}$):

\[ PM_{\textrm{nominal}} = A \cdot \textrm{Size}^E \]

gdzie A jest stałą dobraną doświadczalnie, u nas równą 1.52, Size wartością w KSLOC (tysiącach linii kodu) a E wyraża się wzorem:

\[ E = B + 0.01 \cdot \sum_{i=1}^5 SF_i \]

gdzie B jest stałą dobraną doświadczalnie, u nas równą 0.88, a $SF_i$ to czynniki skali. Wartości czynników skali przedstawia poniższa tabela:

\begin{center}
\begin{tabular}{|l|l|l|} \hline
\textbf{Nazwa czynnika} & \textbf{Ocena} & \textbf{Wartość} \\ \hline
\textbf{Typowość} & Low & 2.96 \\
\textbf{Elastyczność} & High & 2.01 \\
\textbf{Zarządzanie ryzykiem} & Nominal & 5.24 \\
\textbf{Spójność zespołu} & Nominal & 8.29 \\
\textbf{Dojrzałość procesu wytwarzania} & Low & 5.24 \\ \hline
\end{tabular}
\end{center}


Czynnik E jest więc równy $0.88 + 0.01 \cdot 23.74 = 1.11$. Obliczymy teraz pracochłonność projektu:

\[ PM_{nominal} = 1.52 \cdot 14^{1.11} = 28. \]

Uzyskane wyniki znajdują się w tabeli \ref{t:wyniki}:
\begin{table}[h]
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Nazwa} & \textbf{Wartość}\\
\hline
Osobo-miesiące & $28$\\
Osobo-dni & $784$\\
Osobo-godziny & $6120$\\
\hline
\end{tabular}
\end{center}
\caption{Wyniki}
\label{t:wyniki}
\end{table}

Przy założeniu, że koszt zatrudnienia programisty, to 3500 zł miesięcznie, na zatrudnienie 15 osobowego zespołu będziemy potrzebowali 28 * 1,5 * 3500 = 147 000 zł.

\subsection{Harmonogram realizacji przedsięwzięcia}
Harmonogram realizacji przedsięwzięcia został przedstawiony w dokumencie ``harmonogram zadan.pdf''.

\section{Harmonogram wytwarzania dokumentacji}
Dokumentacja będzie tworzona równolegle z implementacją. Zatem programowanie oznacza nie tylko wytwarzanie kodu, ale także
odpowiedniej dokumentacji.

\section[Zarządzanie ryzykiem]{Identyfikacja głównych ryzyk i koncepcja zarządzania nimi}
Poniżej zostały przedstawione podstawowe ryzyka, na które jest narażony projekt oraz sposoby zapobiegania im lub metody radzenia sobie
z nimi. Każde wystąpienie ryzyka będzie odnotowywane.

\subsection{Zmiana priorytetów projektu}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.2
  \item Poziom ryzyka - wysokie
  \item Zapobieganie lub reakcja - nie do uniknięcia
\end{itemize}

\subsection{Konflikty w zespole}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.65
  \item Poziom ryzyka - wysokie
  \item Zapobieganie - dobrze rozdzielone i sprecyzowane zadania, częste dialogi pomiędzy członkami zespołu, wspólne wyjścia mające na
        celu integracje członków zespołu
  \item reakcja - dialog pomiędzy członkami konfliktu
\end{itemize}

\subsection{Niepełne zaangażowanie członków zespołu}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.5
  \item Poziom ryzyka - wysokie
  \item Zapobieganie - odpowiednie motywowanie członków zespołu, dobrze sprecyzowany harmonogram zadań na najbliższy czas oraz
        codzienny system monitorowania postępów
\end{itemize}

\subsection{Zły projekt interfejsu użytkownika}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.25
  \item Poziom ryzyka - bardzo wysoki
  \item Zapobieganie - budowanie prototypów i rozbudowane testy z użytkownikami
\end{itemize}

\subsection{Awaria serwera repozytorium}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.05
  \item Poziom ryzyka - średni
  \item Zapobieganie - cotygodniowe tworzenie kopii zapasowej (również na serwerze zastępczym)
  \item Reakcja - zawartość repozytorium oraz system zostały przeniesione na serwer zastępczy
\end{itemize}

\subsection{Brak prądu}
\begin{itemize}
  \item Prawdopodobieństwo wystąpienia - 0.1
  \item Poziom ryzyka - wysoki
  \item Reakcja - korzystanie z agregatów prądotwórczych
\end{itemize}

\section{Koncepcja zarządzania zmianami wymagań i kodu}
Zmiany wymagań można podzielić na dwie grupy. W pierwszej znajdować się będą zmiany wewnętrzne, czyli takie na które zespół ma wpływ i może
sprawować nad nimi kontrolę. Jednak większość zmian należy do drugiej grupy, na które ani programista ani użytkownik nie maja wpływu. Są to
zmiany, które zależą od czynników zewnętrznych.\\
Zmiany wymagań są nieuniknione, dlatego koniczne jest opracowanie koncepcji zarządzania nimi. Poniżej zostały przedstawione kroki według których
będzie przebiegać zmiana wymagań i kodu.

\subsection{Rozpoznanie konieczności wprowadzenia zmian}
Zespół lub programista zdaje sobie sprawę z potrzeby wprowadzenia zmiany. Wymagana jest dokładna analiza problemu mająca na celu utwierdzenie
się w przekonaniu, że wprowadzenie zmian będzie korzystniejsze i opłacalne w stosunku do pozostania przy starych rozwiązaniach.

\subsection{Jednostka kontrolująca przebieg wprowadzenia zmian}
Ostateczna decyzja o wprowadzeniu zmian spoczywa na kierowniku przedsięwzięcia (Project Manager). To on po analizie wpływu zmiany na plan
przedsięwzięcia i budżet zatwierdza lub odrzuca ją. W związku z tym żadna zmiana nie może być wprowadzona przed oficjalnym ustaleniem jej
z Project Managerem.

\subsection{Planowanie wprowadzenia zmian}
Planowanie wprowadzenia zmian wymusza ponowną analizę wszystkich wymagań. Wyróżniane są wymagania bazowe, ``stare'' (te, z których zrezygnowano),
``nowe'' (świeżo dodane do systemu) oraz zmodyfikowane (te, do których zostały wprowadzone zmiany).

\subsection{Korzystanie z systemu kontroli zmian}
Zostanie uruchomiony system mający na celu kontrolowanie i gromadzenie wprowadzanych zmian. To przy jego użyciu zainteresowane zamianą strony będą
się komunikować. W szczególności korzystając z tego systemu Project Manager poinformuje o decyzji wprowadzenia zmiany lub rezygnacji z niej.

\subsection{Hierarchiczne wprowadzanie zmian}
Wprowadzeniu zmiany nie może być przeprowadzone samodzielnie przez członka zespołu bez porozumienia się z resztą, ponieważ zmiana może mieć
wpływ na cały projekt. W związku z tym wymagane jest hierarchiczne wprowadzenie zmian ``od góry do dołu''. W pierwszej kolejności konieczne jest
wprowadzenie aneksu do dokumentu wizji, a następnie korekta wymagań, projektu, kodu i testów.

\section{Koncepcja zarządzania jakością}
W celu zapewnienia wysokiej jakości tworzonego systemu zostaną wprowadzone poniżej opisane zasady.

\subsection{Zdefiniowanie ról i odpowiedzialności}
Każdy członek zespołu powinien mieć zdefiniowaną rolę oraz zakres obowiązków związanych z pełnioną funkcją. W projekcie zostały wyróżnione
następujące role: Project Manager, Analityk, Architekt, Kierownik podprojektu, Programista, Tester.

\subsection{Planowanie i monitorowanie prac}
W określonych fazach wytwarzania systemu każdy powinien mieć ściśle sprecyzowane cele i zdefiniowany zgodnie z nimi plan prac na najbliższy
okres. Ponad to wymagane jest codzienne monitorowanie postępu prac. Ewentualne problemy lub możliwe opóźnienia czasowe powinny być zgłaszane
natychmiastowo osobie która zleciła zadanie.

\subsection{Zaangażowanie ludzi}
Wymagane jest zaangażowanie członków zespołu w procesie wytwarzania systemu. Zatem konieczna jest odpowiednia motywacja, a co za tym idzie
system pochwał i wynagrodzeń za dobrze wykonane zadanie. Ponadto ważnym jest aby zespół wspólnie dążył do zwiększenia jakości tworzonego
systemu. W związku z tym planowana jest organizacja wyjść mających na celu integrację zespołu.

\subsection{Praca z repozytorium}
Repozytorium kodu projektu znajduje się pod adresem:
\begin{center}
% 	\verb+http://code.google.com/p/waszafota/source/+
	\verb+http://waszafota.googlecode.com/svn/+
\end{center}
W skład repozytorium wchodzą następujące katalogi:
\begin{itemize}
	\item \verb+trunk+ - kopia robocza kodu źródłowego i dokumentacji oraz opis ewentualnych błędów,
	\item \verb+branches+ - rozgałęzienia repozytorium, używane na wypadek tworzenia równolegle kilku wersji programu,
	\item \verb+tags+ - obrazy zatwierdzonych wersji systemu.
\end{itemize}
W podkatalogu dokumentacja katalogu trunk znajdować się będą źródła wszystkich dokumentów dotyczących projektu złożonych w systemie \LaTeX.
Nazwa pliku \verb+.tex+ ma być taka sama, jak nazwa dokumentu. W przypadku, gdy do plików źródłowych konieczne będzie dołączenie innych plików,
np. grafik, wymagana jest zgodność nazw. W katalogu z dokumentacją powinny znajdować wyłącznie pliki konieczne do wygenerowania dokumentu
(w~szczególności nie powinny tam się znaleźć dokumenty \verb+.ps+ i \verb+.pdf+).

\subsection{Praca z kodem źródłowym}
Zasady pracy z kodem źródłowym zostały opisane w dokumencie \emph{Standard kodowania}.

\subsection{Kontrola kodu}
W celu wykrycia błahych błędów już w pierwszym etapie tworzenia oprogramowania, wymagane jest sprawdzenie wytworzonego fragmentu kodu
przez osobę, która nie uczestniczyła w procesie jego wytwarzania jeszcze przed przekazaniem go do testowania.

\subsection{Testowanie}
Testowanie jest bardzo ważnym etapem w procesie tworzenia oprogramowania, dlatego w naszym projekcie będziemy na nie zwracać szczególną uwagę.
Do testowania kodu \verb+PHP+ zostanie użyty pakiet \verb+SimpleTest+, a kodu \verb+Pythona+ - \verb+PyUnit+. Oba pakiety służą do przeprowadzania
automatycznych testów jednostkowych. Każda klasa po napisaniu będzie musiała przejść przez testerów, którzy przy pomocy wspomnianych pakietów
będą je gruntownie testować.

Osobne testy będą dotyczyć interfejsu, czyli strony internetowej i jej poprawnego działania. Szczególna uwaga będzie poświęcona temu, żeby portal
wyświetlał się poprawnie we wszystkich najpopularniejszych przeglądarkach internetowych oraz skrypty \verb+JavaScript+ działały bezbłędnie
i nie obciążały zbytnio komputerów użytkoników.

\subsection{Raportowanie błędów}
Wszystkie znalezione błędy powinny zostać zgłoszone w podkatalogu \verb+error+ katalogu \verb+trunk+ wraz z opisem błędu, sytuacji,
w jakiej został wykryty oraz możliwymi przyczynami.

\end{document}
